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FOREWORD 

The  National  Communications  System  (NCS)  is  an  organization  of  the  Federal 
Government  whose  membership  is  comprised  of  23  Government  entities.  Its 
mission  is  to  assist  the  President,  National  Security  Council,  Office  of 
Science  and  Technology  Policy,  and  Office  of  Management  and  Budget  in: 

o  The  exercise  of  their  wartime  and  non-wartime  emergency  functions  and 
their  planning  and  oversight  responsibilities, 

o  'The  coordination  of  the  planning  for  and  provision  of  National 
Security/Emergency  Preparedness  communications  for  the  Federal 
Government  under  all  circumstances  including  crisis  or  emergency. 

In  support  of  this  mission  the  NCS  has  developed  the  Emergency  Preparedness 
Management  Information  System  (EPMIS)  to  permit  the  Manager,  NCS  and  the 
designated  Resource  Allocation  Officer  (RAO)  to  respond  effectively  to  declared 
national  emergencies.  This  is  in  direct  support  of  the  survivability  and 
endurability  objectives  addressed  by  Executive  Order  12472  and  National 
Security  Decision  Directive  97. H This  report  represents  a  system  design 
specification  of  the  Expert  System  Enhancement  to  the  Resource  Allocation 
Module  (XTRAM)  of  EPMIS.  XTRAM, will  assist  the  RAO  in  utilizing  EPMIS,  for 
allocation  and  use  of  limited  telecommunication  assets  in  times  of  crises  and 
emergencies.  ' 
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1 .0  INTRODUCTION 


The  Office  of  the  Manager,  NCS,  requires  timely,  accurate 
information  about  the  status  of  communications  resources  during 
national  emergencies  and  declared  disasters.  This  led  to  the 
realization  that  an  automated  decision  support  system  would  be  useful 
to  NCS  Emergency  Management  Teams,  which  play  a  significant  role  in 
the  monitoring  and  resolution  of  such  situations. 

The  Emergency  Preparedness  Management  Information  System 
( EPMIS ) ,  which  is  designed  to  allow  the  Manager,  NCS,  to  respond  to 
declared  national  emergencies,  is  an  integral  part  of  the  National 
Emergency  Telecommunications  Management  System.  EPMIS  is  a  user- 
oriented,  decision-support  tool  designed  to  assist  the  Manager,  NCS, 
in  the  performance  of  his  assigned  emergency  communications 
management  mission  by  providing  timely  information  about  the  residual 
communications  capabilities  and  the  outstanding  National  Security 
Emergency  Preparedness  (NSEP)  communications  requirements  of  the 
nation . 

Delta  Information  Systems  was  contracted  to  develop  an  Expert 
System  Enhancement  to  the  Resource  Allocation  Module  (XTRAM)  for 
EPMIS.  The  function  of  XTRAM  is  to  serve  as  an  advisor  or  consultant 
to  the  Resource  Allocation  Officer  (RAO)  in  allocating  scarce 
communications  resources,  especially  in  times  of  national  emergency. 
The  RAO  has  the  use  of  the  Emergency  Preparedness  Management 
Information  System  (EPMIS),  which  is  basically  a  custom-designed  file 
management  system  that  keeps  track  of  the  availability  of 
communications  resources  and  the  demands  upon  them.  XTRAM  is 
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designed  to  obtain  pertinent  information  from  EPMIS  (just  as  the  RAO 
would  do  without  XTRAM)  and  produce  recommended  resolutions  to 
requests  for  Telecommunications  services,  freeing  the  RAO  from  much 
of  the  data  analysis  process. 

EPMIS  was  developed  using  the  INGRES  relational  database 
management  system,  and  currently  functions  on  a  Digital  Equipment 
Corporation  (DEC)  MICROVAX  II  multi-user  computer  system  operating 
under  the  VMS  operating  system.  Many  users  can  access  the  EPMIS 
database  concurrent 1 y .  Users  interface  with  the  EPMIS  system  by 
means  of  text-based  menus  presented  on  a  computer  monitor,  with 
keyboard  driven  data  entry;  that  is,  users  must  press  keys  on  a 
computer  keyboard  in  order  to  interact  with  the  EPMIS  program. 

XTRAM  is  an  artificial  intelligence  expert  system,  and  was 
developed  using  the  Automated  Reasoning  Tool  (A.R.T.).  XTRAM 
currently  runs  on  DEC  VAXstation  II  single-user,  multi-tasking 
workstation.  The  VAXstation  has  a  19"  high-resolution  monitor, 
standard  keyboard,  and  a  three  button  mouse.  The  XTRAM  program  takes 
full  advantage  of  the  VAXstation  features.  XTRAM  is  basically  a 
mouse  driven  program  with  little  keyboard  interaction  needed.  The 
user  moves  a  pointer  on  the  monitor  (via  the  mouse)  to  an  option  he 
wants  to  perform,  and  pushes  one  of  the  buttons  on  the  mouse  in  order 
to  select  the  option. 

Since  the  VAXstation  is  multi-tasking,  more  than  one  program  can 
be  controlled  and  displayed  on  the  monitor  concurrently.  A  full 
EPMIS  window  can  be  displayed  on  the  monitor  while  the  XTRAM  program 
is  running.  If  the  user  wishes  to  access  EPMIS  at  any  time  while  the 
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XTRAM  program  is  running  (or  idle),  the  user  needs  to  just  move  the 
mouse  pointer  to  the  EPMIS  window  and  press  a  mouse  button. 

Currently,  EPMIS  and  XTRAM  are  running  on  two  physically 
separate  computer  systems  communicating  through  a  data  link.  The 
purpose  of  this  report  is  to  present  the  results  of  an  investigation 
in  which  methods  to  integrate  the  EPMIS  and  XTRAM  software  systems 
into  one  software  system,  residing  on  one  computer,  were  evaluated. 
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2.0  SUMMARY 


2 . 1  Overview 

In  this  report,  two  alternatives  are  described  in  which  the 
XTRAM  program  can  be  integrated  in  to  the  existing  EPMIS  environment. 
The  EPMIS  environment  consists  of  two  software  modules  (EPMIS 
application  program  and  Damage  Assessment  Module)  and  a  database 
residing  on  a  super-micro  MICROVAX  II  computer  and  a  third  module 
(Mapping  Graphics  Module)  residing  on  an  80386  PC  micro  computer  used 
as  an  EPMIS  terminal.  All  of  the  modules  in  the  EPMIS  environment 
must  access  the  EPMIS  database  at  one  time  or  another.  The  80386 
machine  and  the  MICROVAX  II  communicate  through  a  communications 
link.  This  report  analyzes  the  issues  and  topics  regarding 
integration  taking  into  consideration  the  existing/planned  purchases 
of  hardware,  software  and  on-going  integration  efforts. 

The  first  alternative  (Alternative  1)  consists  of  the  XTRAM 
program  executing  on  the  80386  PC  along  with  the  Mapping  Graphics 
Module,  communicating  with  the  EPMIS  database  through  a  network 
communications  link. 

The  second  alternative  (Alternative  2)  consists  of  the  XTRAM 
program  executing  on  the  MICROVAX  II  along  with  the  EPMIS  database, 
Damage  Assessment  Module,  and  EPMIS  application  program. 

Either  alternative  would  provide  the  required  functionality 
needed  for  an  integrated  system,  but  the  alternatives  differ  in 
performance,  price  and  features.  This  report  addresses  all  factors 
involved  in  selecting  the  alternatives,  and  an  in  depth  description 
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of  each  alternative  along  with  comparisons  between  the  two 
al ternati ves . 

2 . 2  Recommendations 

The  issue  which  clearly  separated  the  two  alternatives  mentioned 
above  is  performance.  Of  the  two  system  alternatives  mentioned, 
Alternative  1  consists  of  XTRAM  running  on  a  80386  PC  connected  to 
the  MICROVAX  II,  and  Alternative  2  consists  of  XTRAM  running  on  the 
MICROVAX  II  along  with  the  EPMIS  application  program  and  Damage 
Assessment  Module.  In  both  alternatives  the  NEXPERT  OBJECT  expert 
system  development  tool  is  recommended  for  XTRAM  development. 

When  considering  the  80386  vs.  the  MICROVAX  II  approach,  the 
performance  of  the  80386  approach  should  be  significantly  higher  due 
to  the  higher  processing  speed  of  the  80386  (even  when  the  overhead 
of  the  communications  link  is  taken  into  consideration).  The 
performance  increase  in  using  NEXPERT  on  a  PC  is  estimated  at  10  to 
15  times  the  present  XTRAM  performance  level. 

As  more  users,  each  potentially  using  XTRAM,  use  the  system, 
more  processing  power  becomes  necessary.  The  processing  of  XTRAM 
(possible  multiple  XTRAMs)  in  the  MICROVAX  II,  along  with  processing 
needed  by  the  other  modules  executing  on  the  MICROVAX  II,  would  not 
only  severely  degrade  XTRAM  performance,  but  also  degrade  performance 
of  the  other  modules  which  access  the  EPMIS  database. 

The  added  processing  power  of  a  80386  in  addition  to  the 
MICROVAX  II  will  give  the  entire  system  added  performance.  XTRAM 
processing  will  not  interfere  with  EPMIS  performance  on  the  MICROVAX 
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XTRAH.  When 


II  with  the  exception  of  database  accesses  required  by 
many  EPMIS/XTRAM  users  are  using  the  system,  XTRAM  will  be  processing 
on  multiple  80386  machines  (5.5  MIPS  each)  instead  of  many  XTRAM 
processes  on  a  single  MICROVAX  II  (0.9  MIPS). 

Of  the  two  alternatives  described,  Alternative  1  is  recommended 
for  XTRAM  integration.  With  the  advantage  in  both  pr i ce/performance 
and  accommodations  for  future  plans  (fly-away),  the  80386  XTRAM 
technique  outweighs  the  MICROVAX  approach. 
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3.0  XTRAM/EPMIS  DESCRIPTION 
3.1  EPMIS 


The  Emergency  Preparedness  Management  Information  System 
(EPMIS),  an  integral  part  of  the  National  Emergency 
Telecommunications  Management  System,  is  designed  to  allow  the 
Manager,  NCS,  to  respond  to  declared  national  emergencies.  EPMIS  is 
a  user-or i ented ,  decision-support  tool  designed  to  assist  the 
Manager,  NCS,  in  the  performance  of  his  assigned  emergency 
communications  management  duties  by  providing  timely  information 
about  the  residual  communications  capabilities  and  the  outstanding 
National  Security  Emergency  Preparedness  (NSEP)  communications 
requirements  of  the  nation.  The  following  sections  describe  the 
present  and  proposed  future  implementations  of  EPMIS. 

3.1.1  Present  Implementation 

EPMIS  was  developed  using  the  INGRES  relational  database 
management  system  and  currently  functions  on  a  Digital  Equipment 
Corporation  (DEC)  MICROVAX  II  multi-user  computer  system  running 
under  the  MicroVMS  operating  system  (see  Table  3-1).  The  multi-user 
system  environment  allows  several  users  access  to  the  EPMIS  database 
concurrentl y .  The  EPMIS  user  interface  consists  of  a  text-based  menu 
system,  presented  on  a  DEC  VT-220  monitor,  and  keyboard-controlled 
data  entry  (i.e.  users  must  press  keys  on  a  computer  keyboard  in 
order  to  make  menu  selections  and/or  enter  data). 

In  the  present  implementation,  EPMIS  and  XTRAM  can  be  run 
concurrently  on  separate  machines.  While  EPMIS  is  running  on  the 
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Table  3-1  -  EPMIS  Hardware/Software  Configuration 


Hardware 


System 

Memory 

Storage  Capacity 
Processor  Speed 
Communications 

Display  Type 
Portabi 1 i ty 

Software 


:  MicroVAX  II 
:  5  Mb 
:  142  Mb 
:  0.9  MIPS 
:  Ethernet, 

Asynchronous  RS-232 
:  VT-220 
:  Non-Portable 


Operating  System  : 

Communications  : 

Appl ications 

Database  Management 
Database  Communications: 
High-level  Language  : 


MicroVMS  5.0 
DecNET 

INGRES  RDBMS 
INGRES/NET 
VAX  FORTRAN 


MicroVAX  II,  XTRAM,  running  on  a  VAXStation  II  workstation,  can 
access  EPMIS  via  an  Ethernet  connection  by  emulating  an  EPMIS 
terminal.  As  far  as  EPMIS  is  concerned,  XTRAM  appears  to  be  a 
typical  EPMIS  terminal.  The  multi-windowing  user  interface  on  the 
XTRAM  VAXStation  II  allows  the  user  to  open  an  XTRAM  window  and  an 
EPMIS  window  concurrent! y .  However,  because  of  the  two  computer 
configuration  and  special  terminal  requirements,  XTRAM  cannot  run 
from  a  standard  EPMIS  terminal. 


3.1.2  Proposed  Changes 

The  original  EPMIS  environment  that  the  current  XTRAM 
communicates  with  will  have  changed  by  the  time  the  EPMIS-XTRAM 
integration  is  performed.  The  EPMIS  software  package  has  already 
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changed  versions  from  3.0  to  4.0.  Also,  the  integrations  of  EPHIS 
modules  other  than  XTRAM  are  presently  underway  and  are  expected  to 
be  finished  prior  to  the  EPMIS-XTRAM  integration. 

Prior  to  the  XTRAM  integration,  EPMIS  will  be  integrated  with  a 
new  Damage  Assessment  Module  and  a  Mapping  Graphics  Enhancement.  The 
Damage  Assessment  Module,  developed  by  Roland  and  Associates,  will 
provide  EPMIS  with  improved  blast,  radiation,  and  fall-out  effects 
assessment  capabilities.  It  will  be  implemented  on  the  EPMIS 
MicroVAX  II  in  a  direct  sof tware-to-sof tware  integration  with  EPMIS. 
The  new  damage  assessment  module  is  a  more  complex  damage  modeling 
module  than  the  one  that  presently  exists  in  EPMIS.  While  an 
official  Integration  Control  Document  (ICD)  for  the  Damage  Assessment 
Module  integration  was  not  available  for  this  study,  it  appears  that 
the  integration  of  the  Damage  Assessment  Module  will  not  affect  the 
integration  of  XTRAM.  The  physical  integration  of  the  DAM  is 
scheduled  for  mid  June  1989. 

The  Mapping  Graphics  Enhancement,  developed  by  TITAN  Systems, 
will  provide  EPMIS  with  a  user  interface  capable  of  graphically 
depicting  the  location  and  status  of  telecommunication  systems  and 
networks,  communication  facilities,  and  other  critical  resources  and 
assets.  The  enhancement  will  also  allow  the  EPMIS  user  to  update  the 
status  of  resources  in  the  EPMIS  data  base.  The  Mapping  Graphics 
Enhancement  is  tentatively  scheduled  to  be  implemented  on  a  20  Mhz 
80386-based  personal  computer  (see  Table  3-2).  An  official  ICD  for 
the  Mapping  Graphics  Enhancement  was  not  available  for  this  study. 

The  mapping  graphics  integration  may  have  an  impact  on  the  planned 
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Table  3-2  -  EPMIS  PC  Hardware/Sof tware  Configuration 


Hardware 

System 

Memory 

Storage  Capacity 
Processor  Speed 
Commun i cat i ons 
Display  Type 
Portabi 1 i ty 

Software 

Operating  System 
Communications 
Appl i cations 

Mapping  Graphics 
Terminal  Emulation 


Compaq  386 
10  Mb 
100  Mb 

20  MHZ,  4.5  MIPS 
Asynchronous  RS-232 
VGA  Gas  Plasma 
Portable 


MS-DOS  3.3 
RTI  PC-Link 

Titan 

DEC  VT-220 


XTRAM  integration.  In  one  of  the  integration  alternatives  proposed 
in  this  study,  the  XTRAM  program  would  execute  in  an  80386 
environment  along  with  the  mapping  graphics  module.  If  the 
government  selects  the  XTRAM  80386  approach,  close  coordination 
between  Delta  Information  Systems  and  TITAN  Systems  will  be  necessary 
for  a  successful  integration. 


3.2  XTRAM 

The  Expert  System  Enhancement  to  the  Resource  Allocation  Module 
(XTRAM)  for  EPMIS  is  designed  to  serve  as  an  advisor  or  consultant  to 
the  Resource  Allocation  Officer  (RAO)  in  allocating  scarce 
communications  resources,  especially  in  times  of  national  emergency. 
Currently,  the  RAO  has  the  use  of  the  Emergency  Preparedness 
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Management  Information  System  (EPMIS),  which  is  basically  a  custom- 
designed  file  management  system  that  keeps  track  of  the  availability 
of  communications  resources  and  the  demands  upon  them.  XTRAM  is 
designed  to  obtain  pertinent  information  from  EPMIS  (just  as  the  RAO 
would  do  without  XTRAM)  and  produce  recommended  resolutions  to 
requests  for  telecommunications  services,  freeing  the  RAO  from  much 
of  the  data  analysis  process. 

3.2.1  Present  Implementation 

XTRAM  is  an  artificial  intelligence  expert  system  developed 
using  the  Automated  Reasoning  Tool  (A.R.T.).  XTRAM  currently  runs  on 
a  DEC  VAXstation  II  single-user,  multi-tasking  workstation  running 
under  the  MicroVMS  operating  system  (see  Table  3-3).  The  VAXstation 
has  a  19"  hi gh-resolution  monitor,  a  standard  keyboard,  and  a  three 
button  mouse,  all  of  which  are  incorporated  into  the  XTRAM  user 
interface.  XTRAM  is  basically  a  mouse-dr i ven,  menu-based  program 
with  little  keyboard  interaction  required.  Using  the  mouse,  the 
XTRAM  user  moves  a  pointer  on  the  monitor  to  a  menu  option  he  wants 
to  perform,  and  clicks  one  of  the  buttons  on  the  mouse  in  order  to 
select  the  option. 

Since  the  VAXstation  is  multi-tasking,  more  than  one  program  can 
be  controlled  and  displayed  on  the  monitor  concurrently .  Each 
program  is  displayed  in  its  own  operating  window;  the  workstation 
user  can  switch  between  windows  by  moving  the  mouse  cursor  into  the 
window  and  clicking  one  of  the  mouse  buttons.  This  feature  allows 
the  concurrent  display  of  an  XTRAM  session  and  an  EPMIS  session  on 
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Table  3-3  -  XTRAH  Hardware/Software  Configuration 


Hardware 

System 

VAXStation  II 

Memory 

16  Mb 

Storage  Capacity 

230  Mb 

Processor  Speed 

0.9  MIPS 

Communications 

Ethernet, 

Asynchronous  RS-232 

Display  Type 

VR-260  19"  High- 

resolution  graphics 

Portabi 1 i ty 

Non-Portable 

Software 

Operating  System 

MicroVMS  5.0 

Communications 

App 1 ications 

DecNET 

Expert  System 

LISP- based  ART  3.2 

Database  Management 

INGRES  RDBMS 

Database  Communications 

INGRES/NET 

High-level  Language 

VAX  C 

one  monitor,  giving  the  user,  to  a  limited  extent,  an  integrated 
EPMIS-XTRAM  system.  If  the  XTRAM  user  wishes  to  access  EPMIS  at  any 
time,  the  user  needs  only  to  move  the  mouse  cursor  to  the  EPMIS 
window  and  click  a  mouse  button. 

In  the  present  implementation,  EPMIS  and  XTRAM  can  be  run 
concurrently  on  separate  machines.  While  EPMIS  is  running  on  a 
MicroVAX  II,  XTRAM,  running  on  the  VAXStation,  can  access  EPMIS  via 
an  Ethernet  connection  by  emulating  an  EPMIS  terminal.  As  far  as 
EPMIS  is  concerned,  XTRAM  appears  to  be  a  typical  EPMIS  terminal.  As 
stated  earlier,  the  VAXStation’s  multi-tasking  feature  also  allows 
the  user  to  open  one  (or  more)  EPMIS  terminal  sessions  which  also 
communicate  with  the  EPMIS  MicroVAX  II  via  the  Ethernet  connection. 
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3.2.2  Proposed  Changes 


The  original  EPMIS  environment  that  the  current  XTRAM 
communicates  with  will  have  changed  by  the  time  the  EPMIS-XTRAM 
integration  is  performed.  The  EPMIS  database  software  package  has 
already  changed  versions  from  3.0  to  4.0.  Changes  to  XTRAM  will  be 
limited  to  modifications  required  to  accommodate  the  new  EPMIS 
database  structure  (e.g.  field  changes,  additions,  and  deletions). 

3.3  Integrated  EPMIS-XTRAM 

3.3.1  System  Reoui rements 

One  of  the  system  requirements  of  the  integrated  EPMIS-XTRAM  is 
that  all  EPMIS  modules  function  together  in  an  integrated  environment 
and  that  all  modules  are  accessible  from  a  single  user  terminal. 

That  is,  a  user  must  be  able  to  invoke  EPMIS,  XTRAM,  the  Damage 
Assessment  Module,  and  the  Mapping  Graphics  Enhancement  from  a  sing'.e 
EPMIS  terminal.  A  second  system  requirement  for  the  integrated 
EPMIS-XTRAM  is  that  the  system  must  be  multi-user,  with  each  user 
having  full  EPMIS  capabilities. 

3.3.2  Functionality 

3.3.2. 1  Proposed  Integration 

The  proposed  integrated  XTRAM/EPMIS  system  would  have  XTRAM  and 
EPMIS  (including  damage  assessment  and  mapping  graphics)  running  from 
a  single  terminal.  A  dedicated  XTRAM  computer  terminal  would  not  be 
needed  and  XTRAM  would  be  accessible  from  every  EPMIS  terminal. 
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Also,  the  concurrent  execution  of  the  EPMIS  and  XTRAM  programs  would 
be  preserved. 

The  existing  XTRAM  user  interface  consists  of  a  series  of 
graphics  windows  with  mouse-cursor  control  over  the  windows.  Very 
little  keyboard  interaction  and  knowledge  of  computers  is  necessary 
to  operate  the  XTRAM  program.  One  goal  for  integration  is  to 
preserve  the  functionalities  of  the  existing  XTRAM  user  interface  as 
much  as  possible. 

The  proposed  EPMIS-XTRAM  integration  alternatives  (to  be 
discussed  in  Section  4.0)  were  designed  so  that  EPMIS  modifications 
would  be  kept  to  a  minimum.  The  extent  of  the  modifications  to  the 
EPMIS  software  environment  would  be  limited  to  adding  an  XTRAM  option 
to  the  EPMIS  Main  Menu  which,  when  selected,  would  initiate  an  XTRAM 
session  running  concurrently  with  EPMIS.  Additional  modifications 
are  dependent  upon  which  integration  alternative  is  implemented. 

EPMIS-XTRAM  Integration  Alternative  1,  in  which  XTRAM  would  be 
implemented  on  an  80386-based  PC  along  with  the  Mapping  Graphics 
Enhancement,  would  require  significant  hardware  and  software 
modifications  to  the  EPMIS  PC  environment  to  implement  XTRAM.  The 
integrated  PC  system  proposed  in  Alternative  1  is  presented  in  Table 
3-4.  This  integration  option  would  reduce  the  portability  of  the 
EPMIS  PC  terminal  environment,  but  would  greatly  increase  its 
capabilities.  Each  EPMIS  PC  terminal  would  have  full  XTRAM 
capabilities,  with  all  of  the  related  processing  being  performed  by 
the  5.5  to  6.5  MIPS  PC. 
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Table  3-4  -  Proposed  EPMIS-XTRAM  Integration  Plan  1  System 


Hardware 

System 

Compaq  386/25 

Memory 

13  Mb 

Storage  Capacity 

1 10  Mb 

Processor  Speed 

25  MHZ,  5.5  MIPS 

Commun i cat i ons 

Ethernet  ( DEPCA ) , 

Asynchronous  RS-232 

Display  Type 

VGA  Color  Graphics 

Portabi 1 i ty 

Non-Portable  (Desktop) 

Software 

Operating  System 

MS-DOS  3.3 

Communications 

DECNet  DOS,  MS-Net, 

INGRES/NET 

Appl ications 

Mapping  Graphics 

Titan 

Expert  System 

NEXPERT  OBJECT 

Terminal  Emulation 

VT-220  (DEC  PCSA ) 

Multitasking 

MS-Windows/386  or 

Desqview 

User  Interface 

NEXPERT  windows/mouse 

building  tools 

High-level  Language 

Microsoft  C 

EPMIS-XTRAM  Integration  Alternative  2,  in  which  XTRAM  would  be 
implemented  on  the  EPHIS  MicroVAX  II,  would  require  significant 
hardware  and  software  modifications  to  the  EPMIS  MicroVAX  II 
environment  to  implement  XTRAM.  The  integrated  MicroVAX  II  system 
proposed  in  Alternative  2  is  presented  in  Table  3-5.  This 
integration  option  would  preserve  the  portability  of  the  EPMIS  PC 
terminals,  but  would  put  the  burden  of  processing  multiple  XTRAM 
sessions  on  the  0.9  MIPS  MicroVAX  II. 

Because  the  proposed  EPMIS-XTRAM  integration  alternatives  were 
designed  so  that  EPMIS  modifications  would  be  kept  to  a  minimum,  the 
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Table  3-5  -  Proposed  EPMIS-XTRAM  Integration  Alternative  2  System 

Hardware 

System 
Memory 

Storage  Capacity 
Processor  Speed 
Communications 

Display  Type 
Portabi 1 i ty 

Software 

Operating  System  :  MicroVMS  5.0 

Communications  :  DECNET 

Appl i cat ions 

Database  Management  :  INGRES  RDBMS 

Database  Communications  :  INGRES/NET 

Expert  System  Shell  :  NEXPERT  OBJECT 

User  Interface  :  NEXPERT  Text  window 

building  tools 

High-level  Language  :  VAX  c 


integration  alternatives  proposed  place  the  bulk  of  the  modification 
burden  on  XTRAM.  The  modifications  to  the  XTRAM  software  environment 
include  converting  the  XTRAM  expert  system  software  to  a  new  expert 
system  shell  platform  (NEXPERT  OBJECT)  and  modifying  the  operator 
interface  to  suit  the  new  hardware/sof tware  implementation. 

Additional  modifications  are  dependent  upon  which  integration 
alternative  is  implemented. 

In  Alternative  1,  the  XTRAM  expert  system  software,  presently 
implemented  in  the  LISP-based  A.R.T.  3.2  expert  system  shell,  would 
be  converted  to  the  C-based  NEXPERT  OBJECT  expert  system  environment. 
Although  A.R.T.  3.2  was  determined  to  be  the  best  expert  system  shell 
available  for  the  VAXStation  II  when  XTRAM  was  developed,  the  current 
study  has  revealed  that  NEXPERT  is,  overall,  the  best  shell  currently 


:  MicroVAX  II 
:  1 3  Mb 
:  300  Mb 
:  0.9  MIPS 
:  Ethernet, 

Asynchronous  RS-232 
:  VT-220 
:  Non-Portable 
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available,  for  both  PC  and  VAX  implementations.  Because  NEXPERT’s 
inference  engine  is  similar  to  that  of  A.R.T.’s,  the  conversion 
effort  would  be  quite  reasonable. 

The  80386-based  PC  hardware  environment  of  Alternative  1  would 
require  significant  modifications  to  the  XTRAH  user  interface  in 
terms  of  implementation;  however,  the  actual  XTRAM  user  interface 
would  not  change  significantly.  Through  Desqview,  "C"  graphics 
libraries,  and  DECNet  DOS,  the  VAXStation  II  multi-windowing,  multi¬ 
tasking  user  environment  can  be  preserved. 

In  Alternative  2,  as  in  Alternative  1,  the  XTRAM  expert  system 
software,  presently  implemented  in  the  LISP-based  A.R.T.  3.2  expert 
system  shell,  would  be  converted  to  the  C-based  NEXPERT  OBJECT  expert 
system  environment.  The  MicroVAX  II  hardware  environment  of 
Alternative  2  would  require  significant  modifications  to  the  XTRAM 
user  interface  in  terms  of  both  implementation  and  appearance. 

Because  the  MicroVAX  II  terminals  would  be  strictly  VT-220  text 
displays,  NEXPERT’s  text  window  user  interface  building  tools  would 
be  used  to  implement  a  text-based,  keyboard-driven  interface  similar 
to  that  of  EPMIS .  EPMIS-XTRAM  concurrent  operation  would  be 
implemented  via  the  MicroVMS  multi-tasking  capabilities,  but  only  one 
application  would  be  displayed  at  a  time.  Switching  between  EPMIS 
and  XTRAM  would  be  accomplished  through  menu  options. 


-  1 1 
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3. 3. 2. 2  FI y-awav 


Current  integration  tasks  involving  the  use  of  80386-based  PCs 
as  EPMIS  terminals  are  significant  steps  toward  EPMIS  portability. 
These  PCs  are  small,  relatively  inexpensive,  and  becoming  very 
powerful.  PC  technology,  as  well  as  computer  technology  in  general, 
is  progressing  very  rapidly.  Significant  advances  in  PC  portability 
continue  to  be  made.  With  the  announcement  of  Intel’s  80486  CPU 
(which  is  completely  compatible  with  the  80386  CPU),  capable  of  15-20 
MIPS  at  the  introductory  clock  speeds,  it  will  not  be  long  until  the 
80486  technology  is  made  portable. 

Another  technological  advance  occurring  in  the  PC  world  is  the 
advancement  of  operating  system  software  to  run  on  these  machines. 
Currently,  the  most  accepted  PC  operating  system  is  DOS.  DOS  is  a 
single-user/single-tasking  operating  system,  which  limits  the  ability 
to  have  multiple  users  access  a  single  PC  without  the  use  of 
additional  software.  DOS  also  has  a  limit  of  640K  addressable 
memory.  There  are  ways  around  these  barriers,  but  DOS  was  not  meant 
to  operate  in  a  large  memory/multi-user  environment. 

Other  multi-user/multi-tasking  operating  systems  that  have  been 
introduced  to  the  PC  environment  are  UNIX  and  OS/2.  These  operating 
systems  are  relatively  new  to  the  PC  environment,  however,  and  many 
software  packages  (database,  networking,  graphics,  etc)  that  are 
necessary  to  build  a  system  such  as  XTRAM  are  not  supported  under 
these  operating  systems  at  the  present  time.  Many  software  vendors 
are  presently  working  towards  making  their  products  available  under 
these  operating  systems. 
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At  the  present  time,  the  ability  to  place  the  entire  EPMIS 
system  (all  modules  included)  in  a  portable  environment  providing  all 
required  EPMIS  functional i ty  is  noi  feasible  due  to  hardware 
constraints,  operating  system  constraints,  and  software  availability. 
With  advances  in  hardware  and  software  technology,  however,  the  EPMIS 
database  could  be  moved  to  into  a  portable  environment,  making  the 
entire  system  portable.  Taking  steps  towards  the  PC  environment  can 
only  be  beneficial  to  the  entire  EPMIS  program. 

3.3.3  Performance 

Because  all  the  modules  (EPMIS  application,  damage  assessment, 
mapping  graphics,  and  XTRAM)  access  the  EPMIS  database,  the 
performance  of  all  modules  is  dependent  upon  the  database  access 
performance.  If  the  EPMIS  database  access  is  slowed  by  other 
processing  going  on  in  the  same  computer,  performance  of  all  modules 
will  suffer.  There  are  two  basic  ways  to  keep  the  database  access  as 
fast  as  possible: 

Put  the  entire  EPMIS  system  on  a  single  computer  which  is 
fast  enough  to  handle  the  processing  of  all  modules  and 
database  access; 

Reduce,  as  much  as  possible,  secondary  processing  (non¬ 
database  access)  on  the  same  computer  as  the  database 
accessing  (distribute  processing). 
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3.3.3. 1  Hardware 

The  proposed  EPMIS  integrated  system  is  quite  different  from  the 
original  EPMIS  system.  This  new  EPMIS  has  increased  hardware  needs. 
The  system  is  also  more  complex  than  previously  thought.  The 
addition  of  mapping  graphics,  XTRAM,  and  a  more  complex  damage 
assessment  module  put  more  of  a  strain  on  the  existing  EPMIS  hardware 
than  the  original  EPMIS  system  did.  Although  physically  possible, 
the  addition  of  all  of  these  modules  into  the  present  EPMIS  hardware 
would  degrade  current  performance  significantly.  There  are  two  basic 
ways  to  integrate  all  of  the  EPMIS  modules  and  not  degrade  system 
performance . 

One  way  would  be  to  place  all  modules  on  one  computer  powerful 
enough  to  handle  all  modules.  Although  this  approach  is  possible 
with  present  technology,  the  integrated  system  would  be  no  closer  to 
portability  than  it  is  today.  In  addition,  when  considering  the 
existing  EPMIS  hardware  along  with  hardware  still  on  order  as  well  as 
time  and  money  spent  towards  on-going  integration  efforts,  this 
alternative  would  significantly  increase  the  costs  of  the  EPMIS-XTRAM 
integration  and  would  not  be  feasible  at  the  present  time. 

A  second,  more  practical  technique  would  be  to  split  the 
processing  between  multiple  computers.  In  this  approach,  the 
database,  for  example,  would  reside  on  one  computer,  and  other 
CPU- intensive  modules  would  reside  on  a  second  computer.  The  pre- 
XTRAM  integrated  EPMIS  system  is  configured  this  way.  The  MicroVAX 
II  runs  the  EPMIS  database,  and  80386-based  PCs  running  the  graphics 
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applications  are  used  as  terminals;  each  EPMIS  user  would  have  an 
80386  processor,  and  a  slice  of  the  MicroVAX  II  processor. 

3. 3. 3. 2  Software 

The  proposed  EPMIS  integrated  system  is  quite  different  from  the 
original  EPMIS  system.  This  new  EPMIS  has  increased  software 
performance  requi rements .  The  system  is  also  more  complex  than 
previously  thought.  The  addition  of  mapping  graphics,  XTRAM,  and  a 
more  complex  damage  assessment  module  put  more  of  a  strain  on  the 
existing  EPMIS  hardware  than  the  original  EPMIS  system  did.  Thus, 
the  XTRAM  program  performance  must  be  improved  to  minimize  its 
hardware  requi rements ,  freeing  more  processing  power  for  the  other 
EPMIS  modules.  In  particular,  the  expert  system  shell  must  be 
upgraded  to  improve  its  performance. 

The  present  XTRAM  system  was  built  using  LISP-based  ART  in  a 
workstation  environment.  LISP-based  ART,  and  LISP-based  shells  in 
general,  are  excellent  for  rapid  prototyping  and  development. 

However,  LISP-based  shells  consume  large  amounts  of  computer 
resources  and  typically  run  very  slow  in  a  conventional  computing 
environment.  LISP-based  environments  are  also  not  very  portable 
across  hardware  platforms. 

"C”-based  shells,  on  the  other  hand,  are  typically  smaller  and 
faster,  and  are  very  portable  across  hardware  platforms.  In 
integrating  XTRAM  into  EPMIS,  it  is  desirable  to  make  XTRAM  as  fast 
as  possible,  and  also  to  be  able  to  run  it  in  a  smaller  computing 
environment  than  it  does  presently  (to  accommodate  future  portability 
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plans).  It  is  therefore  desirable  to  use  a  "C"  based  expert  system 
development  shell  for  integration. 

A  major  factor  in  the  selection  of  a  new  expert  system  shell  is 
the  shell’s  level  of  compatibility  with  existing  XTRAM  code.  XTRAM 
was  originally  written  using  LISP-based  ART,  which  runs  on 
workstations.  Selecting  a  shell  with  a  similar  rule  structure  and 
similar  inferencing  techniques  would  simplify  the  rule  conversion 
necessary  for  integration.  The  present  XTRAM  employs  a  feature  found 
in  LISP-based  ART  (and  many  other  LISP-based  workstation  shells) 
known  as  hypothetical  reasoning.  Hypothetical  reasoning  is  a 
powerful  feature  found  in  most  high-end  shells.  It  is  typically  not 
found  in  smaller,  "C"-based  shells  due  to  the  large  amounts  of 
computer  resources  needed  for  its  implementation.  If  the  shell 
chosen  for  integration  does  not  have  hypothetical  reasoning, 
additional  rules  will  have  to  be  developed  to  compensate. 

Another  factor  affecting  the  selection  of  a  new  expert  system 
shell  is  the  ability  of  the  shell  to  run  on  many  hardware  platforms 
with  little  modification.  If  an  expert  system  shell  is  portable,  an 
application  developed  using  that  shell  can  easily  be  transported  to 
other  hardware  platforms.  This  is  an  important  feature  if  a 
different  hardware  platform  for  EPMIS  is  chosen  in  the  future. 

It  is  important  that  the  shell  selected  have  a  good  software 
development  environment.  A  good  development  environment  will  speed 
software  development  considerably,  as  compared  to  a  shell  that  does 
not  provide  a  good  development  environment.  The  shell  should  also 
possess  adequate  user  interface  building  capabilities.  Since  the 
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existing  graphical  XTRAM  interface  is,  to  the  extent  possible,  to  be 
preserved,  a  shell  with  tools  capable  of  building  such  an  interface 
is  desirable. 

Some  of  the  shells  available  provide  built-in  database  interface 
facilities.  In  using  these  facilities,  database  queries  can  be 
performed  from  rules.  The  advantage  of  a  shell  that  provides  this 
type  of  facility  is  the  work  that  can  be  avoided  in  building  a  custom 
database  interface  for  a  particular  application  from  scratch. 

The  reputation  of  the  selected  shell  is  also  important.  A  shell 
that  has  been  proven  and  has  been  in  existence  for  a  long  period  of 
time  is  less  likely  to  cause  problems  due  to  software  bugs  in  the 
shell  during  development. 
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4.0  SYSTEM  ALTERNATIVES 
4. 1  General 


This  section  contains  the  XTRAM  system  integration  alternatives 
developed  from  the  integration  study  performed  by  Delta  Information 
Systems.  Each  alternative  is  described  in  detail,  followed  by  a 
system  design  specification  including  all  materials  and  associated 
prices  of  items  required  to  implement  each  alternative.  Following 
the  alternative  descriptions  is  an  alternative  analysis  comparing  all 
alternatives.  This  is  followed  by  the  recommendation  of  the 
particular  alternative  to  be  used  for  integration. 

Cost/Performance  evaluation  assumptions 

Each  system  alternative  description  contains  a  price  performance 
evaluation  for  that  alternative.  Certain  assumptions  were  made  in 
order  to  perform  a  uniform  evaluation  of  each  alternative. 

The  first  assumption  is  the  existence  of  a  MICROVAX  II  in  its 
current  hardware  configuration,  and  the  existence  of  80386  machines 
used  as  terminals.  The  evaluation  uses  relative  costs  associated 
with  additions  of  hardware  and  software  necessary  for  each  individual 
integration  alternative.  Both  alternatives  recommend  the  use  of  an 
expert  system  shell  which  is  common  to  both  alternatives,  so  the 
expert  system  shell  performance  is  not  a  variable  in  the  evaluation. 
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4.1.1  Hardware  Candidates 


The  factors  that  hardware  were  evaluated  on  for  the  XTRAM 
integration  include:  existing  hardware  used  for  current  non-XTRAM 
integration,  ability  to  run  software  packages  recommended  for 
integration,  practicality  for  future  fly-away  plans,  and  key  database 
performance  features. 

The  first,  and  probably  the  most  important  factor  considered  is 
the  existing  hardware  presently  being  used  for  integration.  As 
mentioned  previously,  there  are  current  integration  tasks  occurring 
at  the  present  time  involving  the  integration  of  a  damage  assessment 
module  and  mapping  graphics  module  with  EPHIS. 

The  second  factor  is  the  ability  of  the  hardware  to  run  key 
software  packages  that  are  recommended  for  integration. 

The  third  factor  is  the  practicality  of  the  particular  hardware 
platform  regarding  future  fly-away  plans.  The  proposed  hardware 
configuration  should  provide  one  step  closer  towards  portability. 

The  last  factor  is  the  performance  of  the  system  from  a  database 
management  point  of  view.  All  modules  in  EPMIS  access  the  EPMIS 
database  at  one  time  or  another.  In  order  for  optimum  performance  of 
the  entire  system,  a  hardware  configuration  which  allows  for  fast 
database  access  should  be  used.  The  key  points  in  hardware  which  are 
critical  for  fast  database  access  are:  Processing  speed  (MIPS),  data 
bus  throughput,  and  Disk  access  time.  (Note:  The  disk  access  time 
for  the  existing  MicroVAX  II  is  37  milliseconds  which  is  sub-optimal 
by  today's  standards) 
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4. 1 . 1 . 1  MicroVAX-Based  Systems 


An  evaluation  of  the  current  MicroVAX  family  was  performed  in  an 
effort  to  determine  the  best  EPMIS-XTRAM  integration  environment. 
Because  the  XTRAM  expert  system  application  is  presently  implemented 
on  a  VAXStation  II,  its  implementation  on  a  MicroVAX-based  system, 
when  combined  with  the  implementation  of  the  EPMIS  database,  will 
require  the  performance  of  a  more  powerful  MicroVAX.  The  principal 
advantage  of  a  MicroVAX  implementation  of  the  integrated  EPMIS-XTRAM 
system  is  that  both  the  XTRAM  software  and  the  EPMIS  software  would 
be  completely  compatible  with  a  more  powerful  VAX.  In  addition, 
because  both  EPMIS  and  XTRAM  would  reside  on  the  same  machine, 
database  communications  between  the  two  would  not  be  limited  by  a 
communications  link  (e.g.  Ethernet). 

The  integrated  EPMIS-XTRAM  system  could  be  implemented  on  the 
present  EPMIS  MicroVAX  II.  However,  multiple,  concurrent  XTRAM 
sessions  on  the  0.9  MIPS  machine  would  severely  degrade  the 
performance  of  the  system.  In  order  to  implement  both  EPMIS  and 
XTRAM  on  a  single  MicroVAX,  an  upgrade  to  a  more  powerful  machine  is 
required.  Two  options  available  that  provide  two  levels  of 
performance  above  the  MicroVAX  II  are  the  MicroVAX  3400  and  the 
MicroVAX  3800. 

The  MicroVAX  3400  operates  at  2.4  MIPS,  which  is  approximately 
2i  times  the  CPU  performance  of  the  MicroVAX  II.  In  addition,  the 
data  throughput  of  the  MicroVAX  3400  is  3  times  the  throughput  of  the 
MicroVAX  II,  which  will  greatly  reduce  the  database  access  times  for 
both  XTRAM  sessions  and  EPMIS  terminal  sessions.  The  MicroVAX  3400 
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can  be  equipped  with  a  maximum  of  28  Mb  RAM  and  900  Mb  of  disk 
storage,  both  significantly  higher  than  the  corresponding  maximums  of 
the  MicroVAX  II. 

The  integrated  EPMIS-XTRAM  system  would  require  a  MicroVAX  3400 
equipped  with  16  Mb  RAM,  300  Mb  of  disk  storage  (standard),  and  a 
networking  package  to  communicate  with  the  Mapping  Graphics 
Enhancement  PC.  A  MicroVAX  3400  configured  as  such,  with  all 
associated  operating  system  and  support  software,  would  be  list 
priced  at  approximately  $66,000. 

The  MicroVAX  3800  operates  at  4.5  MIPS,  which  is  approximately 
4i  times  the  CPU  performance  of  the  MicroVAX  II.  In  addition,  the 
data  throughput  of  the  MicroVAX  3800  is  4  times  the  throughput  of  the 
MicroVAX  II,  which  will  greatly  reduce  the  database  access  times  for 
both  XTRAM  sessions  and  EPMIS  terminal  sessions.  The  MicroVAX  3800 
can  be  equipped  with  a  maximum  of  64  Mb  RAM  and  1.2  Gb  of  disk 
storage,  both  significantly  higher  than  the  corresponding  maximums  of 
the  MicroVAX  II. 

The  integrated  EPMIS-XTRAM  system  would  require  a  MicroVAX  3800 
equipped  with  16  Mb  RAM,  300  Mb  of  disk  storage  (standard),  and  a 
networking  package  to  communicate  with  the  Mapping  Graphics 
Enhancement  PC.  A  MicroVAX  3800  configured  as  such,  with  all 
associated  operating  system  and  support  software,  would  be  list 
priced  at  approximately  $105,000. 
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4 . 1  . 1  . 2  SUN-Based  Systems 


An  evaluation  of  the  current  SUN  workstation  technology  was 
performed  in  an  effort  to  determine  the  best  EPMIS-XTRAM  integration 
environment.  The  XTRAM  expert  system  application  is  presently 
implemented  on  a  VAXStation  II;  the  EPMIS  database  application  is 
implemented  on  a  MicroVAX  II.  Both  XTRAM  and  EPMIS  could  be 
implemented  concurrently  on  a  SUN  Microsystems  machine.  The 
principal  advantage  of  a  SUN  implementation  of  the  integrated  EPMIS- 
XTRAM  system  is  that  new  system  would  be  much  more  powerful.  In 
addition,  because  both  EPMIS  and  XTRAM  would  reside  on  the  same 
machine,  database  communications  between  the  two  would  not  be  limited 
by  a  communications  link  (e.g.  Ethernet). 

There  are  several  types  of  SUN  computers  available  that  could  be 
employed  for  the  implementation  of  the  integrated  EPMIS-XTRAM  system, 
including  the  SUN-3  series,  the  SUN-4  series,  and  the  SUN 
SPARCstation  series.  The  SUN  SPARCstation  330  appears  to  be  the  most 
viable  candidate  for  the  EPMIS-XTRAM  integration.  The  SPARCstation 
330  is  a  RISC  processor-based  computer  which  operates  at  16  MIPS*, 
which  is  significantly  greater  than  the  CPU  performance  of  the 
MicroVAX  II.  In  addition,  the  data  throughput  of  the  SPARCstation 
330 ’s  (VME  bus)  produces  15-20  times  the  throughput  of  the  MicroVAX 
II  (Q  bus),  which  will  greatly  reduce  the  database  access  times  for 


*  The  performance  rating  of  a  Reduced  Instruction  Set  Computer 
(RISC),  measured  in  MIPS,  is  not  directly  comparable  to  the 
performance  ratings  of  Complex  Instruction  Set  Computers  (CISCs), 
also  measured  in  MIPS,  because  RISC  machines  require  more 
instructions  than  CISC  machines  to  perform  the  same  task. 
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both  XTRAH  sessions  and  EPMIS  terminal  sessions.  The  SPARCstation 
330  can  be  equipped  with  a  maximum  of  40  Mb  RAM  and  1.3  Gb  of  disk 
storage,  both  significantly  higher  than  the  correspondi ng  maximums  of 
the  MicroVAX  II. 

The  integrated  EPMIS-XTRAM  system  would  require  a  SPARCstation 
330  equipped  with  16  Mb  RAM,  327  Mb  of  disk  storage  (standard),  and  a 
networking  package  to  communicate  with  the  Mapping  Graphics 
Enhancement  PC.  A  SPARCstation  330  configured  as  such,  with  all 
associated  operating  system  and  support  software,  would  be  list 
priced  at  approximately  $42,500. 

4 . 1 . 1 . 3  80386-Based  Systems 

An  evaluation  of  the  current  80386-based  PC  technology  was 
performed  in  an  effort  to  determine  the  best  EPMIS-XTRAM  integration 
environment.  Because  the  XTRAM  expert  system  application  is  highly 
complex,  its  implementation  on  an  80386-based  PC,  when  combined  with 
the  implementation  of  the  Mapping  Graphics  Enhancement,  will  require 
the  performance  of  a  25  MHz  or  33  MHz  80386-based  PC.  While  a  16  MHz 
or  20  MHz  80386-based  PC  could  handle  this  load,  the  response  times 
to  user  interactions  would  be  less  than  those  of  a  25  Mhz  machine. 

The  33  MHz  80386-based  PCs  offer  an  increase  in  processing  power 
of  25*  to  50*  over  the  25  MHz  PCs  (7.5  to  8.5  MIPS  vs.  5.5  to 
6.5  MIPS).  This  advantage  in  processing  power  is  somewhat  offset, 
however,  by  the  fact  that  the  33  MHz  PCs  are  a  relatively  recent 
introduction,  while  the  25  MHz  PCs  are  well  established.  This  fact, 
coupled  with  the  recent  announcement  of  Intel’s  80486  CPU,  which 
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benchmarks  at  15-20  MIPS  (at  25  MHz,  with  clock  speeds  projected  to 
60  MHz)  and  will  be  priced  about  the  same  as  the  33  MHz  80386  CPU, 
indicates  that  the  next  logical  step  up  from  the  25  MHz  80386-based 
PC  would  be  to  an  80486-based  PC.  The  25  MHz  80386-based  PC, 
therefore,  is  a  better  candidate  for  the  EPMIS-XTRAM  Integration 
Alternative  1  system  than  the  33  MHz  PC. 

A  survey  of  available  25  MHz  80386-based  PCs  was  performed  in 
which  the  PCs  were  evaluated  based  on  several  factors,  including  list 
price,  performance,  documentation,  setup,  ease  of  use, 
serviceability,  and  value.  The  comparisons  were  performed  on 
similarly  configured  systems:  4  Mb  RAM,  32  to  256  Kb  cache  memory, 
one  high-density  floppy  (except  the  Northgate  PC,  which  comes  with 
two),  a  100  to  150  Mb  ESDI  hard  disk,  and  a  VGA  board  and  monitor. 

From  a  field  of  eighteen  machines,  four  25  MHz  80386-based  PCs, 
the  Northgate  Elegance  3000,  the  Compaq  Deskpro  386/25,  the  Dell 
System  325,  and  the  IBM  M70-A21  were  selected  as  the  leading 
candidates.  Of  these  four  PCs,  the  Northgate  Elegance  3000  v,ao> 
selected  as  the  preferred  EPMIS-XTRAM  integration  platform.  The 
Northgate  Elegance  3000  had  the  highest  reported  CPU  speed  of  all  of 
the  PCs  evaluated  at  6.2  MIPS,  followed  by  the  IBM  M70-A21  at  5.8 
MIPS,  and  the  Compaq  Deskpro  386/25  and  the  Dell  System  325,  which 
tied  at  5.6  MIPS. 

The  Northgate  PC  offers  the  best  package  of  standard  features  of 
the  four  the  leading  candidates.  The  Northgatn  PC’s  256  Kb  cache 
memory  is  significantly  greater  than  the  IBM  M70-A21  PC’s  64  Kb  cache 
memory  and  the  32  Kb  cache  memories  of  the  Dell  System  325  and  Compaq 
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Deskpro  386/25  PCs.  The  Northgate  PC  is  the  only  PC  tested  that 
comes  with  MS-DOS  4.01  (or  3.3)  installed  on  the  formatted  hard  disk; 
the  others  require  a  separate  operating  system  purchase.  The 
Northgate  PC  is  also  the  only  PC  tested  that  comes  with  both  a  54" 

1 . 2  Mb  floppy  drive  and  a  34"  1.44  Mb  floppy  drive;  the  others 
include  only  the  54"  1.2  Mb  floppy  drive. 

The  Northgate  PC  is  the  only  PC  among  the  four  leading 
candidates  to  feature  a  tower  design.  This  tower  design  includes 
five  free  expansion  slots  (after  the  installation  of  I/O,  disk 
controller,  and  video  boards),  ten  half-height  mounting  positions 
(for  disk  drives),  and  all  controls  (power,  reset,  keyboard  disable, 
key  lock,  indicator  lights)  of  the  front  panel.  The  expansion  slots 
are  mounted  vertically,  allowing  easy,  top-of-case  access  to  the 
expansion  board  cables. 

The  Dell  System  PC  is  housed  in  a  standard  AT~style  case  with 
six  free  expansion  slots  (after  the  installation  of  disk  controller 
and  video  boards)  and  five  half-height  mounting  positions  (for  disk 
drives).  The  sixth  expansion  slot  is  freed  because  the  serial  and 
parallel  I/O  is  included  on  the  mother  board.  The  Dell  System  PC’s 
controls  are  somewhat  inconvenient;  although  the  indicator  lights  and 
the  key  lock  are  on  the  front  panel,  the  power  switch  is  on  the  rear 
of  the  unit  and  there  is  no  reset  switch. 

The  Compaq  PC  is  also  housed  in  an  AT-style  case,  with  three 
free  expansion  slots  (after  the  installation  of  I/O,  disk  controller, 
and  video  boards)  and  five  half-height  mounting  positions  (for  disk 
drives).  Compaq  also  offers  an  optional  disk  expansion  unit  that 
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allows  for  up  to  Gb  of  disk  storage.  The  Compaq  PC’s  controls  are 
sparse;  there  are  no  indicator  lights,  key  lock,  or  reset  switch  and 
the  power  switch  is  at  the  rear. 

The  IBM  PC  is  housed  in  a  small  footprint  case  designed  to  save 
desk  space.  However,  this  small  case  limits  the  expandability  of  the 
system;  it  features  only  three  free  expansion  slots  (before  disk 
controller  installation)  and  one  full-height  mounting  position 
(limiting  the  disk  storage  capacity  to  300  Mb,  the  largest  available 
hard  disk).  The  serial  and  parallel  I/O  and  video  are  implemented  on 
the  mother  board,  keeping  at  least  two  slots  free.  These  slots, 
however,  are  Micro  Channel  slots,  for  which  there  are  relatively  few 
peripherals  available  at  the  present  time. 

In  terms  of  documentation  and  serviceabi 1 ity ,  the  Northgate 
Elegance  3000  again  took  top  honors.  Its  documentation  is  well 
organized,  informative,  and  well-illustrated,  and  its  technical 
support,  which  includes  next-day  on-site  service,  is  quite  good.  The 
Northgate  PC  was  found  to  be  the  best  value  among  the  four 
candidates,  combining  the  second-lowest  list  price  with  the  highest 
performance  and  best  standard  features  package. 

Company  and  product  reputation  is  another  factor  considered  in 
the  selection  of  the  EPMIS-XTRAM  integration  system.  Compaq  is  the 
most  well-known  among  the  four  candidates;  its  reputation  is  built  on 
the  reliability  and  widespread  application  of  the  Compaq  family  of 
computers.  This  reputation,  however,  is  more  than  offset  by  the  list 
price  of  the  Compaq  Deskpro  386/25.  The  Northgate  Elegance  3000  is 
produced  by  Northgate  Computer  Systems,  a  company  with  a  much  lower 
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profile  than  Compaq,  but  with  over  20  years  experience  in  the  PC 
computer  field. 

Because  the  PC  selected  will  be  implementing  the  Mapping 
Graphics  Enhancement,  the  question  of  graphics  adapters  and  monitors 
was  addressed.  All  of  the  PCs  studied  are  equipped  with  VGA  boards 
and  multi-scanning  monitors  in  their  standard  configurations. 

However,  a  new  generation  of  VGA  video  boards,  called  enhanced  or 
super  VGA,  provides  increased  resolution  (800x600  vs.  VGA’s  640x480) 
at  about  the  same  cost  as  VGA.  Although  the  Mapping  Graphics 
Enhancement  presently  does  not  take  advantage  of  this  higher 
resolution,  the  capability  should  be  provided  for  in  the  integration 
implementation  system. 

This  impacts  the  selection  of  the  multi-scanning  monitor  in 
particular;  all  but  one  of  the  multi-scanning  monitors  presently 
available  have  maximum  specified  horizontal  frequencies  of  35  MHz, 
which  is  slightly  lower  than  the  horizontal  frequency  required  to 
display  super  VGA.  Only  the  NEC  Multisync  Plus  monitor  is  specified 
to  handle  higher  frequencies  (the  Multisync  Plus  is  also  capable  of 
displaying  non-interlaced  1024x768  resolution  video). 

Based  upon  the  evaluations  performed  in  this  study,  the  system 
described  in  Table  4-1  was  selected  as  the  EPMIS-XTRAM  integration 
development  system.  The  Northgate  Elegance  3000  was  the  highest 
rated  80386-based  PC  system  in  terms  of  performance,  configuration, 
and  value.  The  80  Mb  SCSI  disk  drive  was  selected  for  its  fast 
(16  ms)  access  time;  80  Mb  of  storage  was  determined  to  be  sufficient 
for  development  purposes.  The  Paradise  VGA  board  was  selected  for 
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Table  4-1  -  80386-Based  Integrated  EPMIS-XTRAM  Development  System 


Hardware 

System 

:  Northgate  Elegance  3000 

Memory 

:  8  Mb 

Storage  Capacity 

:  80  Mb  (SCSI) 

Processor  Speed 

:  25  MHZ,  6.2  MIPS 

Communications 

:  Ethernet  ( DEPCA ) , 
Asynchronous  RS-232 

Graphics  Board 

:  Paradise  VGA  Graphics 

Monitor  Type 

:  NEC  Multisync  Plus 

Portabi 1 i ty 

:  Non-Portable  (Tower) 

I  Software 

Operating  System 

:  MS-DOS  3.3  or  4.01 

Communications 

:  DECNet  DOS,  MS-Net, 
INGRES/NET 

1  Applications  \ 

Expert  System 

:  NEXPERT  OBJECT 

Terminal  Emulation 

:  VT-220  (DEC  PCSA) 

Multitasking 

:  Desqview  w/QEMM 

User  Interface 

:  NEXPERT  windows/mouse 
building  tools 

High-level  Language 

:  Microsoft  C 

List  Price 

:  $16,000 

its  high-quality  graphics  and  overall  value.  The  Multisync  Plus 
multi-scanning  monitor  was  selected  because  it  allows  for  future 
video  board  upgrade  (e.g.  to  super  VGA)  without  replacing  the 
monitor. 


4 . 1 . 1 . 4  Comparison  of  Hardware  Alternatives 

Each  of  the  hardware  alternatives  discussed  above  has  its 
relative  strengths  and  weaknesses.  The  two  MicroVAX  alternatives 
offer  the  advantages  of  total  software  compatibility  and  transparent 
migration  to  more  powerful  VAXes  for  both  EPMIS  and  XTRAM.  However , 


the  two  MicroVAX  alternatives  offer  the  unfavorable  combination  of 
the  highest  prices  and  the  poorest  performances  (in  terms  of  CPU 
speed  and  data  throughput)  among  the  alternative  systems.  In 
addition,  the  MicroVAX  alternatives  are  poor  candidates  for  future 
fly-away  systems;  at  present,  portability  is  not  a  design  goal  for 
the  MicroVAX  family  of  computers. 

The  SUN  SPARCstation  330  alternative  offers  the  best 
pri ce/performance  combination,  far  outdistancing  the  other  systems  in 
terms  of  performance.  In  fact,  the  SPARCstation  330  would  be  the 
leading  candidate  if  the  EPMIS-XTRAM  integration  were  being  done  from 
scratch;  it  offers  the  capability  to  implement  the  entire  EPMIS 
system,  including  XTRAM  and  the  Mapping  Graphics  Enhancement,  on  a 
single  machine.  However,  because  the  SPARCstation  330  is  a  RISC 
machine,  none  of  the  existing  EPMIS,  XTRAM,  or  Mapping  Graphics 
Enhancement  software  (without  modification)  would  be  transparently 
compatible  with  the  hardware.  In  addition,  the  SUN  alternative  is 
not  a  good  candidate  for  future  fly-away  systems;  at  present, 
portability  beyond  a  desktop  model  is  not  a  design  goal  for  the 
SPARCstation  family  of  computers. 

The  80386-based  PC  alternative  offers  a  price/performance 
combination  comparable  to  that  of  the  SUN  alternative  ($2667/MIP  vs. 
$2656/MIP )  at  a  much  lower  overall  cost.  With  the  forthcoming 
advances  in  PC  technology  (e.g.  the  80486  CPU),  a  PC-based  system 
will  have  the  capability  to  implement  the  entire  EPMIS  system, 
including  XTRAM  and  the  Mapping  Graphics  Enhancement,  on  a  single 
machine.  In  addition,  this  fully  integrated  EPMIS  PC  could  be 
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contained  in  a  portable  enclosure  for  full  fly-away  capability.  By 
developing  the  integrated  EPMIS-XTRAM  system  software  on  an 
80386-based  PC  now,  the  transition  to  the  future  fly-away  environment 
will  be  greatly  simplified. 

Table  4-2  -  Price/Performance  Comparison  of  Hardware  Alternatives 


MicroVAX  3400 

MicroVAX  3800 

SPARCstation  330 

80386-based  PC 

CPU 
Speed , 
MIPS 

2.4 

4.5 

1 6 ( RISC ) 

5.6  -  6.5 

Bus 

Speed, 

Mb/s 

2.5 

3.3 

20 

8 

List 

Price, 

$ 

66,000 

105,000 

42,500 

16,000 

Present 

Porta¬ 

bility 

Tower 

Tower 

Tower 

Desktop/Tower 

Future 
Porta- 
bi  1  i  ty 

Tower 

Tower 

Desktop 

Portable 

4.1.2  Expert  System  She! 1  Candidates 

All  expert  system  shell  candidates  described  are  capable  of 
running  on  all  hardware  candidates  mentioned  in  the  previous  section. 
The  factors  on  which  the  expert  systems  were  evaluated  include 
operating  speed,  portability  across  hardware  platforms,  level  of 
compatibility  with  existing  XTRAM  code,  hypothetical  reasoning 
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capabilities,  software  development  environment,  user  interface 
building  capabilities,  built-in  database  interface  facilities,  and 
reputation . 

4 . 1 . 2 . 1  ART-IM  ( Inference ) 

ART-IM  is  a  "C"-based  version  of  the  ART  that  was  used  to 
develop  XTRAM.  ART-IM  is  compatible  with  ART  code  developed  in  the 
LISP-based  ART,  with  the  exception  of  the  hypothetical  reasoning 
capabilities.  Because  Inference  produces  both  ART  packages,  ART-IM 
is  very  compatible  with  the  existing  XTRAM  code.  In  addition,  ART-IM 
is  approximately  ten  times  faster  (on  identical  hardware  platforms) 
than  the  LISP-based  ART.  Since  it  is  written  in  "C"  it  would  be 
relatively  easy  to  embed  in  an  existing  application;  however,  ART-IM 
is  a  recent  introduction  into  the  market,  and  thus  has  not  yet  been 
proven . 

4. 1 .2.2  K££  ( Intel! icorp) 

KEE  is  a  LISP-based  expert  system  shell  that  features 
hypothetical  reasoning,  a  built-in  INGRES  interface,  and  other 
features  similar  to  the  LISP-based  ART,  making  it  a  good  candidate 
for  a  prototyping  environment.  However,  because  it  is  LISP-based,  it 
requires  large  amounts  of  computing  resources  (e.g.  memory,  disk 
space)  and  is  much  slower  than  the  "C"-based  shells,  making  it  a  poor 
candidate  for  an  implementation  environment.  Also,  since  it  is 
written  in  LISP  it  would  be  relatively  difficult  to  embed  in  an 
existing  application. 
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4 . 1 . 2 . 3  KES  ( Software  A&E ) 


KES  is  a  "C"-based  expert  system  shell.  KES  needs  little  in  the 
way  of  computer  resources,  is  very  portable,  and  is  well-established 
in  the  expert  system  market.  Since  it  is  written  in  ”C"  it  would  be 
relatively  easy  to  embed  in  an  existing  application.  One  of  KES’s 
chief  features  is  that  it  provides  multiple  inference  engines,  which 
can  be  used  for  problems  requiring  multiple,  independent  solutions. 
Since  XTRAM  is  one  specific  problem,  however,  this  feature  is  of 
little  value.  KES  also  does  not  have  a  very  good  software 
development  environment  at  the  present  time.  KES  does  not  provide 
hypothetical  reasoning. 

4. 1 . 2.4  NEXPERT  OBJECT  (Neuron  Data) 

NEXPERT  OBJECT  is  a  "C"-based  expert  system  shell  that  runs  on  a 
variety  of  platforms.  NEXPERT’s  "C"-based  implementation  has  enabled 
NEXPERT  to  be  ported  to  DEC  VAXes,  IBM  PCs,  Apollos,  Suns,  and  IBM 
mainframes.  Also,  it’s  ”C”  implementation  makes  it  95*  source  code 
compatible  across  hardware  platforms.  The  only  differences  across 
hardware  platforms  are  subtle  user  interface  differences.  It  is  one 
of  the  most  powerful  expert  system  development  tools  available  on  a 
PC.  It  is  well  established  and  has  been  proven  in  many  applications. 
It  has  also  received  favorable  reviews  by  many  AI  and  PC  magazines. 

Similarities  to  the  LISP-based  ART  include  a  frame  based 
knowledge  representation  and  a  data  driven  archi tecture.  It  has  a 
robust  mouse/window  driven  user  interface  for  development,  and  an 
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extensive  user  interface  development  tool  for  building  a  custom  user 
interface  for  an  application. 

Although  the  use  of  NEXPERT  would  require  coding  changes 
regarding  rule  conversion,  the  user  interface  coding  would  be 
simplified  compared  to  other  expert  system  shells.  In  addition, 

XTRAH  would  become  very  portable,  which  is  a  very  important  feature 
if  an  EPHIS  hardware  platform  change  were  made  in  the  future. 

In  addition  to  the  features  previously  mentioned,  NEXPERT  can 
also  be  easily  embedded  into  existing  applications  with  its  “callable 
interface".  The  ability  to  easily  embed  one  application  into  another 
is  an  excellent  feature  that  can  be  used  to  physically  link  programs 
together  in  one  environment.  As  with  other  "C"-based  expert  systems, 
NEXPERT  does  not  feature  hypothetical  reasoning;  however,  NEXPERT 
does  feature  built-in  INGRES  interface  capabilities  on  various 
hardware  platforms.  NEXPERT  has  also  received  excellent  product 
reviews  by  many  AI  and  PC  magazines. 
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Table  4-3  -  Expert  System  Shell  Comparison 


Language 


Simi lari ty 
to  ART 


Hypothetical 

Reasoning 


Portabi 1 i ty 


User  interface 
building  tools 


Development 
envi ronment 


Reputation 


ART-IM  KEE  KES  NEXPERT 


In  the  first  EPMIS-XTRAM  integration  alternative,  XTRAM  would  be 


implemented  on  an  80386-based  PC  along  with  the  Mapping  Graphics 
Enhancement.  The  integrated  PC  system  proposed  in  Alternative  1  is 
presented  in  Table  4-4  and  illustrated  in  Figure  4.1.  This 
integration  option  would  reduce  the  portability  of  the  EPMIS  PC 
terminal  environment,  but  would  greatly  increase  its  capabilities. 


Table  4-4  -  Proposed  EPMIS-XTRAM  Integration  Alternative  1  System 


Hardware 

System 

80386-based  PC 

Memory 

8  Mb 

Storage  Capacity 

110  Mb 

Processor  Speed 

25  MHz,  5.5  -  6.5  MIPS 

Communications 

Ethernet  (DEPCA) , 

Asynchronous  RS-232 

Display  Type 

VGA  Color  Graphics 

Portabi 1 i ty 

Non-Portable 

Software 

Operating  System 

MS-DOS  3.3 

Commun i cat ions 

DECNet  DOS,  INGRES/NET 

Appl i cations 

Mapping  Graphics 

TITAN 

Expert  System 

NEXPERT  OBJECT 

Terminal  Emulation 

VT-220 

Multitasking 

MS-Windows/386  or 

Desqview 

User  Interface 

NEXPERT  user  interface 

building  tools,  "C" 

graphics  libraries 

High-level  Language 

Microsoft  C 
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SYSTEM  ALTERNATIVE 


EPMIS 

DATA 

BASE 


Each  EPHIS  PC  terminal  would  have  full  XTRAM  capabilities,  with  all 
of  the  related  processing  being  performed  by  the  5.5  -  6.5  MIPS  PC. 

In  Alternative  1,  communications  between  the  EPMIS  MicroVAX  II 
and  the  EPMIS  PC  terminal  could  be  .handled  both  asynchronously 
( RS-232  modem,  for  fly-away  applications)  and  via  high  performance 
Ethernet  connections  (for  on-site  applications).  The  XTRAM  expert 
system  software,  presently  implemented  in  the  LISP-based  A.R.T.  3.2, 
would  be  converted  to  a  C-based  expert  system  environment  to  increase 
performance.  The  hardware  and  software  systems  recommended  for 
Alternative  1  are  discussed  below. 

4.2.1 . 1  Hardware 

The  hardware  requirements  for  Integration  Alternative  1  are 
detailed  in  Table  4-4.  As  discussed  in  Section  4.1.1,  the 
implementation  of  XTRAM  on  an  80386-based  PC,  in  combination  with  the 
Mapping  Graphics  Enhancement,  would  require  the  processing  power  of  a 
25  MHz  or  33  MHz  machine.  The  survey  of  the  presently  available 
80386-based  PCs  revealed  that  a  25-MHz  80386-based,  non-portable  PC 
would  be  the  best  candidate  for  the  integration.  All  of  the  25  MHz 
80386-based  PCs  examined  were  similar  in  terms  of  performance  and 
features;  the  selection  of  the  integration  PC  would  therefore  be 
based  primarily  on  price. 

A  non-portable  machine  is  recommended  for  the  initial 
EPMIS-XTRAM  integration  because  the  configuration  required  to 
implement  both  XTRAM  and  the  Mapping  Graphics  Enhancement  along  with 
a  modem,  additional  memory,  CD-ROM  etc.  on  a  portable  PC  is  not 
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currently  available.  This  is  true  primarily  due  to  clock  speed 
limitations  and  available  slots  in  portab' a  models.  The  25  MHz 
80386-based  PC,  however,  will  provide  an  excellent  platform  for  the 
transition  to  a  portable,  or  fly-away,  integration  system  when  the 
technology  becomes  available.  The  recent  announcement  of  Intel’s 
80486  CPU  (benchmarked  at  15-20  MIPS  at  introduction)  is  a  good 
indication  that  portable  PCs  with  the  capability  to  run  XTRAM  and  th9 
Mapping  Graphics  Enhancement  concurrently  are  not  far  off.  By 
developing  the  integrated  system  on  a  25  MHz  80386-based  PC, 
upgrading  to  an  80486-based  portable  will  require  virtually  no 
modifications. 

4. 2. 1.2  Software 

4. 2. 1.2.1  Expert  System  Shell 

NEXPERT  OBJECT  is  an  expert  system  shell  that  runs  on  a  variety 
of  platforms.  NEXPERT’s  "C"  based  implementation  has  enabled  NEXPERT 
to  be  transported  to  tha  DEC  VAX,  IBM  PC,  Apollo,  Sun,  and  IBM 
mainframes.  In  addition,  it  is  95*  source  code  compatible  across 
hardware  platforms  as  a  result  of  its  "C"  implementation.  The  only 
differences  across  hardware  platforms  are  subtle  user  interface 
differences.  NEXPERT  OBJECT  is  one  of  the  most  powerful  expert 
system  development  tools  available  for  the  PC  environment.  It  is 
well  established  and  proven  in  many  applications.  It  has  also 
received  favorable  reviews  by  many  AI  and  PC  publications. 

NEXPERT  OBJECT  shares  several  similarities  with  ART  that  will 
facilitate  the  conversion  of  the  XTRAM  software  from  the  LISP-based 
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ART  to  the  "C"-based  NEXPERT.  These  similarities  include  a  frame 
based  knowledge  representation  and  a  data  driven  architecture. 

NEXPERT  has  a  robust  mouse/window  driven  user  interface  for 
development,  and  an  extensive  user  interface  development  tool  for 
building  a  custom  use.  interface  for  an  application. 

Although  the  use  of  NEXPERT  would  require  more  coding  changes 
regarding  rule  conversion,  the  user  interface  coding  would  be  much 
simpler  compared  to  that  of  other  expert  system  shells.  The 
conversion  to  NEXPERT  would  make  XTRAM  very  portable,  an  important 
feature  if  an  EPMIS  hardware  platform  change  were  made  in  the  future. 

In  addition  to  the  features  previously  mentioned,  NEXPERT  can 
also  be  easily  embedded  into  existing  applications.  The  ability  to 
easily  embed  one  application  into  another  is  an  excellent  feature 
that  car.  be  used  to  physically  link  programs  together  in  one 
envi ronment . 

The  NEXPERT  development  package  running  under  MS-Windows  would 
be  used  for  development,  while  the  NEXPERT  runtime  package  (protected 
mode)  running  under  Desqview  independent  of  MS-Windows  would  be  used 
for  XTRAM  deployment. 

4.2. 1 .2.2  Computer  Communications 

The  DECNet-DOS  PC  communications  package,  which  includes 
DECNet-DOS  communications  software  and  a  DEPCA  Ethernet  card,  will  be 
used  to  monitor  and  control  the  network  communications  requirements 
of  both  the  on-site  EPMIS  PC  terminals  and  could  also  be  used  to 
control  the  remote  (asynchronous)  EPMIS  PC  terminals.  This  software 
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package  allows  a  PC  user  to  access  an  Ethernet  network,  and  thus  to 
the  data  available  in  a  DEC  VAX  environment,  via  either  a  direct 
Ethernet  connection.  DECNET-DOS  can  also  run  in  asynchronous 
environments  with  minor  modifications. 

4 . 2 . 1 . 2 . 3  Database  Communications 

At  the  present  time,  NEXPERT  OBJECT  for  the  PC  environment  does 
not  have  a  built-in  INGRES  database  interface.  Neuron  Data,  the 
company  that  makes  NEXPERT,  has  plans  to  develop  such  an  interface  in 
the  near  future.  Code  currently  exists,  as  part  of  the  existing 
XTRAM  software,  to  communicate  with  the  EPMIS  database  without  the 
use  of  a  NEXPERT  built-in  interface.  This  code  is  presently 
operational  in  the  current  XTRAM  implementation  and  would  require 
only  minor  modifications  to  make  it  functional  in  the  NEXPERT 
environment.  The  code  uses  INGRES/NET  which  runs  under  DECNET-DOS 
protocol  to  transparentl y  access  the  EPMIS  database  on  the  MICROVAX 
II.  The  code  is  "C"-based  containing  embedded  database  queries.  The 
database  is  queried  from  inside  the  "C”  routines  and  the  data  is 
converted  into  "C"  variables.  At  this  point,  the  data  is  either 
processed  by  the  "C"  routine  or  loaded  into  the  NEXPERT  knowledge 
base  for  processing.  Permanent  copies  of  EPMIS  data  are  not  stored 
on  secondary  storage  devices  on  the  XTRAM  machine  due  to  the 
necessity  of  the  most  recent  EPMIS  data  for  XTRAM  processing  and  the 
dynamic  nature  of  the  EPMIS  data.  When  EPMIS  data  is  needed  from 
XTRAM,  the  main  EPMIS  database  is  queried  for  the  most  recent  EPMIS 
data . 
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This  code  would  be  used  to  communicate  with  the  EPMIS  database 
using  INGRES/NET,  as  it  does  now.  When  the  NEXPERT  built-in  INGRES 
interface  becomes  available,  a  simple  conversion  will  be  necessary  to 
modify  XTRAM  to  utilize  the  interface. 

4.2. 1 .2.4  User  Interface 

The  combination  of  NEXPERT  OBJECT  user  interface  building  tools 
and  "C"  graphics  libraries,  would  allow  the  generation  of  a 
graphics/mouse  interface. 

4.2. 1 .2.5  Operating  System 

Of  the  operating  systems  available  in  for  80386  environment 
(i.e.  OS/2,  DOS,  UNIX/XENIX),  DOS  is  the  only  one  at  the  present  time 
that  can  accommodate  and  support  all  of  the  software  needed  to  allow 
XTRAM  to  reside  on  an  80386-based  machine.  The  pieces  of  software 
that  are  necessary  for  integration  that  are  not  available  for  the 
other  operating  systems  are  DECNet-DOS  and  INGRES/NET.  Many  software 
vendors  are  currently  working  towards  making  their  products  OS/2  and 
UNIX/XENIX  compatible.  If  and  when  DECNet-DOS  and  INGRES/NET  are 
available  for  the  other  operating  systems,  a  review  of  the 
implementation  of  XTRAM  on  the  PC  may  indicate  that  XTRAM  can  be 
enhanced  by  switching  to  one  of  these  more  powerful  operating 
systems . 


4 


24 


4 . 2 . 1 . 2 . 6  Multi-tasking  Software 


Because  a  true  multi-tasking  operating  system  cannot  be  used,  a 
multi-tasking  software  shell  is  needed  to  provide  a  multi-tasking 
environment.  Requirements  for  multi-tasking  using  XTRAM  on  an  80386 
machine  include  a  multi-tasking  software  product  that  can  handle 
extended  memory  (DOS  protected  mode  -  memory  available  beyond  640  Kb 
with  hardware  limitations  of  16  Mb)  tasks,  as  well  as  expanded  memory 
tasks  (requiring  less  than  640  K  per  task)  running  in  the  DOS 
environment.  A  preliminary  estimate  of  the  system  memory 
requirements  indicates  that  XTRAM  would  run  in  protected  mode  and 
that  the  other  tasks  would  run  in  expanded  memory  (Figure  4.2).  This 
is  a  preliminary  estimate,  however,  and  when  the  tasks  are 
implemented  can  be  optimized  to  achieve  optimum  performance  once  the 
system  becomes  operational. 

There  are  several  software  shells  available  which  allow  multi¬ 
tasking  in  a  DOS  80386  environment.  Desqview  and  MS-Windows  386  are 
two  of  the  most  popular  products  for  multi-tasking.  Of  these  two 
products,  only  Desqview  is  capable  of  allowing  both  protected  mode 
and  expanded  memory  running  at  the  same  time.  Also,  Neuron  Data 
(developers  of  NEXPERT)  used  the  Desqview  memory  manager  (QEMM)  to 
develop  their  run-time  version  of  NEXPERT.  In  addition,  Desqview 
requires  less  memory  overhead  and  is  more  efficient  than  MS-Windows. 

4.2. 1 .3  Computer  Networking 

Integration  Alternative  1  involves  having  XTRAM  run  in  an  80386 
environment  concurrent  with  the  Mapping  Graphics  Enhancement,  with 
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386  DOS  MEMORY  ALLOCATION 


EXPANDED  MEMORY  TASK  DOS  640  K  PARTITION 


EPMIS  running  on  a  HicroVAX  II.  With  the  superior  processing  power 
of  multiple  80386  machines  linked  to  the  MicroVAX  II,  it  is  very 
important  that  the  best  networking  approach  be  taken  so  the  that 
network  is  not  the  limiting  factor,  in  terms  of  performance,  in  the 
integrated  system. 

In  evaluating  the  effectiveness  of  networking  alternatives, 
several  functional i t ies  were  addressed.  The  first,  and  most 
significant,  involves  EPMIS  database  access.  The  PC-1  ink  product  by 
RTI ,  which  is  being  evaluated  for  the  mapping  graphics  integration, 
does  provide  for  data  transfer  (database  queries)  from  EPMIS  to  the 
PC,  but  does  not  allow  for  database  updates  (PC-EPMIS  VAX)  which  is  a 
requirement  of  the  Mapping  Graphics  Enhancement.  The  INGRES/NET 
product  (now  functional  in  the  existing  XTRAM)  does  provide  bi¬ 
directional  database  communication.  XTRAM  requires  that  the  database 
communications  between  the  PC  and  EPMIS  function  in  both  directions. 
INGRES/NET  is  therefore  the  recommended  approach  for  database 
communications. 

The  concurrent  operation  of  XTRAM  and  the  Mapping  Graphics 
Enhancement  in  an  80386  environment  means  that  there  could  be  as  many 
as  three  tasks  running  simultaneously  during  an  EPMIS  session:  XTRAM, 
the  mapping  graphics,  and  a  VT-220  terminal  emulation  (to  control  the 
EPMIS  user  interface  on  the  MicroVAX).  To  implement  the  concurrent 
operation  of  all  three  tasks,  a  communications  protocol  which  allows 
for  multiple  parallel  communications  requests  is  required. 

The  integrated  EPMIS-XTRAM  system  should  be  capable  of  operating 
both  at  the  EPMIS  MicroVAX  II  site  (local)  and  from  a  dial  up  modem 
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line  (fly-away).  The  selected  networking  technique  should  be  capable 
of  handling  both  operating  modes  with  only  minor  configuration 
modifications  to  the  PC  environment.  From  an  evaluation  of  the 
networking  packages  available  for  the  combined  VAX-PC  environment, 
the  following  computer  networking  strategy  was  selected  for  the 
EPMIS-XTRAM  integration  Alternative  1  system. 

For  database  communications,  INGRES/NET  would  be  used. 

INGRES/NET  provides  a  bi-directional  transparent  access  to  databases 
on  remote  computers.  A  program  written  and  running  on  a  PC  can 
contain  an  embedded  database  query  or  update  call.  EPMIS  data  can 
then  be  directly  inserted  into  the  XTRAM  environment.  The  current 
XTRAM  system  uses  INGRES/NET  for  its  database  queries  and  updates  in 
its  current  VAXstation  II  to  MICROVAX  II  communications. 

The  on-site  PC-to-MicroVAX  II  communications  would  be 
implemented  using  DEC’S  Ethernet  network.  This  approach  involves  the 
use  of  a  DECNet-DOS  communications  package  for  the  PC.  The  package 
includes  a  DEPCA  card  (which  is  an  Ethernet  card  for  the  PC)  and 
DECNet-DOS  network  software. 

The  DECNet-DOS  software  will  run  under  DOS  3.3  and  will  control 
all  requests  for  communications  through  the  Ethernet  card  (at  10 
Mbps).  All  of  the  on-site  80386  machines  will  be  physically 
connected  to  the  existing  Ethernet  card  in  the  MicroVAX  II. 

Figure  4.3  illustrates  the  on-site  configuration.  The  MicroVAX  will 
be  set  up  as  the  file  server  in  the  network,  providing  transparent 
PC- to- VAX  file  access. 
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NETWORK  CONFIGURATION  -  DECNET  DOS 


o 

o 

CM 


For  remote  operation,  a  DECrouter  200  communications  device 
could  be  attached  to  the  MicroVAX  II’s  Ethernet  card.  This  would 
allow  for  remote  machines  to  dial  into  the  network  and  provide  the 
same  functionality  as  the  on-site  PCs,  limited  only  by  the  modem 
transmission  rates  employed.  The  only  modifications  required  for 
remote  operation  would  be  configuring  the  PC’s  DECNet-DOS  network 
software  to  access  an  asynchronous  RS-232  serial  port  on  the  machine 
instead  of  the  Ethernet  card  (an  Ethernet  card  will  not  be  required 
for  the  remote  PCs).  The  integrated  EPMIS-XTRAM  remote  operations 
could  have  the  same  functionalities  as  the  on-site  systems  with 
somewhat  reduced  performance  due  to  the  limitations  of  modem 
communications  speeds. 

An  alternative  to  the  above-mentioned  remote  operation 
configuration  would  employ  one  of  several  available  modem  software 
packages  which  would  speed  the  remote  processing  considerably.  The 
modem  software  would  send  commands  to  a  dedicated  80386  machine 
located  at  the  same  site  as  the  EPMIS  database  server,  connected  to 
the  MicroVAX  II  via  the  Ethernet  network.  The  80386  machine  would 
actually  perform  the  processing,  and  only  the  user  interface  input 
and  output  screens  would  have  to  be  transferred  over  the  asynchronous 
communications  line.  This  option  would  provide  a  dramatic  increase 
in  remote  processing  speeds  by  eliminating  the  large  data  transfers 
over  the  modem  lines.  The  remote  system  would  only  require  minimal 
80286  capabilities  (to  support  VGA)  and  thus  could  be  implemented  in 
a  portable  or  laptop  configuration. 
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4.2.2  Cost /Performance  Eval uation 


The  EPMIS-XTRAM  integration  Alternative  1  system  is  an  excellent 
pri ce/performance  alternative.  In  this  alternative,  a  more  powerful 
version  of  the  Mapping  Graphics  Enhancement  80386-based  EPMIS  PC 
terminal  would  be  employed  to  implement  XTRAM  (concurrent  with  the 
Mapping  Graphics  Enhancement).  The  cost  of  the  additional  PC 
performance  required  (both  hardware  and  software)  is  approximately 
$10,000;  this  is  more  than  offset  by  the  large  increase  in  processing 
power.  The  added  processing  power  of  the  80386-based  PC  (5.5  - 
6.5  MIPS),  in  addition  to  that  of  the  EPMIS  MicroVAX  II  (0.9  MIPS), 
will  give  the  integrated  system  a  significant  boost  in  performance. 

The  XTRAM  processing  is  fully  implemented  on  the  more  powerful 
PC  and  thus  will  not  interfere  with  EPMIS  performance  on  the  MICROVAX 
II.  Only  database  accesses  required  by  XTRAM  (and  the  Mapping 
Graphics  Enhancement)  will  occur  on  the  MICROVAX  II.  When  multiple 
EPMIS/XTRAM  users  are  using  the  system,  XTRAM  will  be  processing  on 
multiple  80386  machines  (5.5  MIPS  each)  instead  of  multiple  XTRAM 
processes  running  on  a  single  MICROVAX  II  (0.9  MIPS).  The  relative 
price  performance  for  this  alternative  is  the  cost  of  additional 
hardware  ($4,745)  divided  by  6.4  MIPS  (5.5  for  80386  +  0.9  for 
MICROVAX  II)  =  $741  per  MIPS. 

Another  advantage  this  alternative  provides  is  that  XTRAM  would 
already  be  developed  for  the  fly-away  application  when  the  technology 
becomes  available.  Migration  from  the  non-portable  80386-based  PC 
into  a  portable  environment  (possibly  80486-based)  would  require  only 
a  minimal  effort.  One  disadvantage  this  alternative  poses  is  that  it 
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requires  a  communications  network  to  transfer  data  between  XTRAM  and 
EPHIS;  however,  a  bi-directional  MicroVAX-to-PC  database 
communications  bridge  is  already  required  for  the  EPMIS  to  mapping 
graphics  communications. 

4.2.3  System  Design  Specification 

Implementation  of  this  alternative  involves  XTRAM  residing  on 
the  EPMIS  80386-based  PC.  The  user  would  access  the  XTRAM  system 
through  a  Desqview  multi-tasking  window;  XTRAM  would,  in  turn,  access 
EPMIS  via  either  Ethernet  or  an  asynchronous  serial  connection. 

Figure  4.4  is  an  illustration  of  the  EPMIS-XTRAM  integration 
Alternative  1  system. 

The  current  plan  for  the  EPMIS  PC  environment  is  to  employ  an 
80386-based  PC  with  a  clock  speed  of  20  MHz.  The  implementation  of 
XTRAM  on  the  PC,  concurrent  with  the  Mapping  Graphics  Enhancement, 
will  require  the  processing  power  of  a  25  MHz  machine.  The 
additional  cost  of  the  25  MHz  PC  over  the  cost  of  the  20  MHz  PC  is 
approximately  $4,000  (see  summary  below).  This  fact  should  be  taken 
into  consideration  in  the  integration  of  the  Mapping  Graphics 
Enhancement  with  EPMIS  as  this  integration  will  be  performed  prior  to 
the  XTRAM  integration. 

The  implementation  of  this  alternative  would  require  a  25Mhz 
80386-based  PC,  DECNet-DOS  communi cat ions  package,  the  NEXPERT  OBJECT 
expert  system  development  tool  for  the  PC  (along  with  run-time  module 
and  one  year  of  maintenance),  INGRES  for  the  PC  (including  INGRES- 
NET),  the  MS-Windows  386  (necessary  for  NEXPERT  development)  and 
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Desqview  386  multi-tasking  environment  packages,  and  the  Microsoft 
"C"  programming  development  environment.  A  summary  of  the  items 
required  to  implement  this  alternative  is  listed  below. 

Hardware 

25  MHz  80386-based  PC  15,500** 

20  MHZ  80386-based  PC  (  1  1.6501 _ 

Difference  L- . .  >  3,850 

DECNET-DOS  communications  package  895 

Software 

NEXPERT  OBJECT  (including  licenses)  7,070 


INGRES  for  PC  1,295 
Microsoft  "C"  450 
Desaview _ 200 

Total  Cost  13,760 


4.3  Alternative  Number  Two 

4.3.1  System  Design 

The  second  alternative  consists  of  XTRAM  executing  in  the 
existing  MICROVAX  II.  The  XTRAM  program  would  share  the  MICROVAX 
computer  resources.  This  conf i guration  is  illustrated  in  Figure  4.5. 

4.3. 1 . 1  Hardware 

In  this  alternative,  the  existing  MICROVAX  II  hardware  would  be 
used  for  the  EPMIS/XTRAM  integration.  This  alternative  would  require 
upgrading  the  memory  and  disk  space  of  the  MICROVAX  II  to  attain  a 


**  The  25  MHz  PC  price  used  here  is  for  the  most  expensive 
configuration. 
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total  of  13  Megabytes  of  RAM  and  318  Megabytes  of  disk  space,  with 
XTRAM  running  in  the  same  environment  as  EPMIS,  the  system  memory 
should  be  increased  to  reduce  any  paging  or  swapping  that  may  occur 
due  to  a  lack  of  physical  memory. 

4. 3. 1.2  Software 
4 . 3 . 1 . 2 . 1  Expert  System  Shel 1 

NEXPERT  OBJECT  is  an  expert  system  shell  that  runs  on  a  variety 
of  platforms.  As  mentioned  in  Alternative  1,  NEXPERT’s  "C"  based 
implementation  has  enabled  NEXPERT  to  be  transported  to  the  DEC  VAX, 
IBM  PC,  Apollo,  Sun,  and  IBM  mainframes.  In  addition,  it  is  95* 
source  code  compatible  across  hardware  platforms  as  a  result  of  its 
"C"  implementation.  The  only  differences  across  hardware  platforms 
are  subtle  user  interface  differences. 

Also  as  mentioned  in  Alternative  1,  NEXPERT  OBJECT  shares 
several  similarities  with  ART  that  will  facilitate  the  conversion  of 
the  XTRAM  software  from  the  LISP-based  ART  to  the  "C"-based  NEXPERT. 
These  similarities  include  a  frame  based  knowledge  representation  and 
a  data  driven  architecture.  NEXPERT  has  a  robust  user  interface  for 
development,  and  an  extensive  user  interface  development  tool  for 
building  a  custom  user  interface  for  an  application. 

Although  the  use  of  NEXPERT  would  require  coding  changes 
regarding  rule  conversion,  the  user  interface  coding  would  be  much 
simpler  compared  to  that  of  other  expert  s/.tem  shells.  The 
conversion  to  NEXPERT  would  make  XTRAM  very  portable,  an  important 
feature  if  an  EPMIS  hardware  platform  change  were  made  in  the  future. 
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In  addition  to  the  features  previously  mentioned,  NEXPERT  can 
also  be  easily  embedded  into  existing  applications.  The  ability  to 
easily  embed  one  application  into  another  is  an  excellent  feature 
that  can  be  used  to  physically  link  programs  together  in  one 
environment.  The  VAX  version  of  NEXPERT  also  features  a  built-in 
INGRES  database  interface  for  easy  expert  system/database 
communication . 

4 . 3 . 1 . 2 . 2  Database  Communications 

The  NEXPERT  OBJECT  product  on  the  VAX  has  built-in  INGRES 
database  interface  capabilities.  Although  code  already  exists  from 
the  current  implementation  of  XTRAH  to  interface  with  the  INGRES 
database,  the  built-in  interface  would  be  used  to  provide  for  easy 
software  maintenance. 

4 . 3 . 1 . 2 . 3  User  Interface 
Interface  Option  1: 

NEXPERT  has  a  product  which  allows  for  the  execution  of  the 
expert  system  on  one  computer,  while  the  user  interface  exists  on  a 
different  computer.  In  this  case,  the  expert  system  would  run  on  the 
MICROVAX  II  and  the  user  interface  would  reside  on  the  80386  machine. 
Using  this  capability,  a  graphics/mouse  user  interface  would  be 
available,  and  look  almost  identical  to  the  user  interface  of 
alternative  1 . 

The  only  difference,  as  far  as  the  user  is  concerned,  between 
integration  Alternatives  1  and  2  would  be  that  the  physical  execution 
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of  XTRAM  would  be  taking  place  on  the  MICROVAX  II.  This  alternative 
would  require  some  XTRAM  integration  development  in  an  80386 
environment,  closely  coordinated  with  TITAN  systems,  as  the  XTRAM 
user  interface  would  reside  in  the  same  computer  as  the  mapping 
graphics  module. 


Interface  Option  2: 

A  second  option  for  a  user  interface  for  this  alternative  would 
be  to  use  the  NEXPERT  text  user  interface  building  tool  for  the  VAX 
( VT220 ) .  This  environment  would  consist  of  text  windows  and  cursor 
controlled  scrolling  using  cursor  (arrow)  keys  instead  of  a  graphics 
display  with  mouse  control.  This  approach  would  not  require  any 
XTRAM  integration  development  in  the  80386  environment.  The  user 
interface  would  function  in  a  VT220  environment  handled  by  the  VT220 
terminal  emulation  on  the  80386  terminal. 


4.3.1 .2.4  Operating  System/Multi-tasking  Software 

In  the  current  EPMIS  MICROVAX  II  configuration,  the  VMS 
operating  system  is  used.  VMS  is  a  true  multi-tasking  operation 
system.  Multi-tasking  would  be  achieved  in  a  VT220  environment  by 
using  VMS  spawn  and  subprocess  commands  to  create  a  process  running 
in  the  background  (XTRAM)  while  the  user  has  control  over  the 
terminal  running  another  process  (EPMIS). 


4 


38 


4.3.2  Cost/Performance  Evaluation 


In  this  alternative,  the  existing  MICROVAX  II  with  the 
proposed  additions  of  memory  and  disk  space  would  be  used  for 
integration.  The  enhancements  to  the  MICROVAX  would  cost 
approximately  $11,500  assuming  that  the  current  MICROVAX  presently 
has  5  Megabytes  of  memory  and  142  Megabytes  of  disk  space  (current 
specifications  EPMIS  MICROVAX  communicating  with  current  XTRAM).  If 
three  users  are  using  the  MICROVAX  II  concurrent! y ,  there  is  the 
potential  for  three  XTRAM  sessions  running  at  the  same  time.  In  this 
scenario,  each  user  would  receive  1/3  of  the  0.9  MIPS  of  the  MICROVAX 
CPU.  At  worst  case,  3  users  running  XTRAM  in  the  background  could 
potentially  perform  damage  assessment.  In  this  scenario,  each  task, 
XTRAM  and  damage  assessment  would  share  the  MICROVAX  CPU.  Both  XTRAM 
and  damage  assessment  tasks  must  also  perform  database  accesses  as 
part  of  their  respective  tasks. 

At  best  case  only  one  user  would  be  logged  on  to  the  system, 
running  the  XTRAM  program  only.  In  this  scenario,  the  user  would 
receive  the  full  .9  MIPS  of  performance.  Even  in  this  case,  .9  MIPS 
of  performance  with  XTRAM  and  the  database  accesses  occurring  in  the 
same  machine  is  not  the  best  performance  available  considering  the 
computing  resources  (MICROVAX  II  and  80386)  available.  The  relative 
price  performance  for  this  alternative  is  the  cost  of  additional 
hardware  ($11,500)  divided  by  .9  MIPS  =  $12,777  per  MIPS. 
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4.3.3  System  Design  Specification 

Implementation  of  this  alternative  involves  XTRAM  residing  in 
the  MICROVAX.  The  user  would  access  the  XTRAM  system  from  the  80386 
terminal  using  VT220  terminal  emulation.  A  system  configuration  is 
illustrated  in  Figure  4.6. 

The  implementation  of  this  alternative  would  require  additional 
disk  and  RAM  resources  for  the  MICROVAX  II,  the  NEXPERT  OBJECT  expert 
system  development  tool.  A  list  of  items  necessary  for  integration 
and  their  costs  are  listed  below. 

Hardware 

Additional  Disk  159M  disk  for  MICROVAX  II  RD54 
8M  additional  RAM  for  MICROVAX  II 

Software 

NEXPERT  OBJECT  expert  system  shell  with  1  year 
of  maintenance  (including  runtime)  $10,570 

Monthly  Maintenance  for  Memory  and  Disk  $130 


$5,395 

$6,000 
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4.4  Analysis 


The  issue  which  clearly  separates  the  two  alternatives  mentioned 
above  is  performance.  Of  the  two  system  alternatives  mentioned,  the 
first  consists  of  XTRAM  running  on  a  80386  PC  connected  to  the 
MICROVAX  II,  and  the  second  consists  of  XTRAM  running  on  the  MICROVAX 
II  along  with  EPMIS.  From  a  performance  point  of  view,  no  matter 
which  alternative  is  chosen,  a  considerable  increase  in  XTRAM 
performance  in  a  standalone  mode  on  the  MICROVAX  II  (with  nothing 
else  running)  would  be  realized  using  the  new  “C“  based  NEXPERT  vs. 
the  current  LISP  based  ART  implementation.  The  performance  increase 
in  using  NEXPERT  vs.  LISP  based  ART  is  estimated  at  approximately  3 
to  4  times  the  current  performance  level. 

When  considering  the  80386  vs.  the  MICROVAX  II  approach, 
however,  the  performance  of  the  80386  approach  should  be 
significantly  higher  due  to  the  higher  processing  speed  of  the  80386 
(even  when  the  overhead  of  the  data  link  is  taken  into 
consideration).  The  performance  increase  in  using  NEXPERT  on  a  PC  is 
estimated  at  10  to  15  times  the  present  XTRAM  performance  level. 

As  more  users,  each  potentially  using  XTRAM,  use  the  system, 
more  processing  power  becomes  necessary.  The  processing  of  XTRAM 
(possible  multiple  XTRAMs)  in  the  MICROVAX  II,  along  with  EPMIS  data 
requests  from  the  damage  assessment  and  mapping  graphics  modules, 
would  not  only  severely  degrade  XTRAM  performance,  but  also  degrade 
performance  of  the  other  modules  which  access  the  EPMIS  database. 

The  added  processing  power  of  a  80386  in  addition  to  the 
MICROVAX  II  will  give  the  entire  system  added  performance.  XTRAM 
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will  not  interfere  with  EPMIS  performance  on  the  MICROVAX  II.  Only 
database  accesses  required  by  XTRAM  will  occur  on  the  MICROVAX  II. 
When  many  EPMIS/XTRAM  users  are  using  the  system,  XTRAM  will  be 
processing  on  multiple  80386  machines  (5.5  MIPS  each)  instead  of  many 
XTRAM  processes  on  a  single  MICROVAX  II  (0.9  MIPS). 

Alternative  1  also  has  an  advantage  in  that  its  XTRAM  would 
already  be  in  place  (PC  environment)  for  future  fly-away 
implementation.  Another  step  of  migration  of  XTRAM  into  a  portable 
environment  in  the  future  would  be  unnecessary.  One  potential 
disadvantage  for  alternative  1  involves  the  networking  an 
communications  necessary  for  the  approach,  however,  a  bi-directional 
database  network/communications  scheme  of  some  type  must  be 
implemented  for  the  mapping  graphics  module  regardless  of  which  XTRAM 
integration  alternative  is  chosen. 

Even  though  the  performance  of  Alternative  2  is  less  than  that 
of  Alternative  1,  the  performance  of  Alternative  2  can  be  increased 
by  migrating  to  a  more  powerful  VAX  with  more  processing  power.  This 
migration  could  be  made  with  total  software  compatibility  (no 
modifications  to  XTRAM).  This  migration  compatibility  is  one  the 
major  strong  points  of  the  VAX  family  of  computers. 
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Table  4-4:  Comparison  of  System  Alternatives 


Alternative  1  Alternative  2 

80386  MICROVAX  II 


Combined 

Processing 

Power 

7  MIPS 

0.9  MIPS 

Cost 

$22,000 

$22,000 

Cost  per 

MIPS 

$3400/MIPS 

$24, 000/MIPS 

Portabi 1 i ty 
Potential 

Excel  lent 

Fai  r 

Transparent 

Software 

Migration 

NO 

YES 

Estimated 
Response  time 
vs.  Present 

10  times  faster 

Same 
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4.4.1 


Of  the  two  alternatives  described,  alternative  1  is  recommended 
for  XTRAM  integration.  With  the  advantage  in  both  price/performance 
and  accommodations  for  future  plans,  the  80386  XTRAM  technique 
outweighs  the  MICROVAX  approach. 
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